home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930339.txt < prev    next >
Internet Message Format  |  1994-06-04  |  10KB
  1. Date: Fri, 31 Dec 93 04:30:02 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #339
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Fri, 31 Dec 93       Volume 93 : Issue  339
  11.  
  12. Today's Topics:
  13.                      Ohio TCP/IP address updates
  14.                     ucsd.edu : swamik@ele.uri.edu
  15.                          What does this mean?
  16.  
  17. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  18. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  19. Problems you can't solve otherwise to brian@ucsd.edu.
  20.  
  21. Archives of past issues of the TCP-Group Digest are available
  22. (by FTP only) from UCSD.Edu in directory "mailarchives".
  23.  
  24. We trust that readers are intelligent enough to realize that all text
  25. herein consists of personal comments and does not represent the official
  26. policies or positions of any party.  Your mileage may vary.  So there.
  27. ----------------------------------------------------------------------
  28.  
  29. Date: Thu, 30 Dec 93 10:33:28 EST
  30. From: samalott@sampc.cmhnet.org (Stephen A. Malott)
  31. Subject: Ohio TCP/IP address updates
  32. To: n8fow@wsu.n8fow.ampr.org_tcp-group@ucsd.edu
  33.  
  34. I have e-mailed you a copy of N8EMR's latest (12/25/93) Ohio IP address list.
  35. Gary's email addresses appear at the top, but here they are for any other
  36. interested parties:
  37.   Gary W. Sanders     Internet: gws@n8emr.cmhnet.org
  38.                       Packet:   n8emr@n8jyv.#cmh.oh.usa.na
  39. Hope this helps you!
  40.       ================================================================                Stephen A. 'SAM' Malott      Packet:  N8JYV@N8JYV.#CMH.OH.USA.NA                                             Internet: samalott@sampc.cmhnet.org
  41.  
  42. ------------------------------
  43.  
  44. Date: Thu, 30 Dec 1993 22:50:55 +0100 (MET)
  45. From: pe1kda%pe1kda@pi8yrc.ampr.org
  46. Subject: ucsd.edu : swamik@ele.uri.edu
  47. To: tcp-group@pa2aga.igg.tno.nl
  48.  
  49. Date: Thu, 30 Dec 93 22:30:14 GMT
  50. Message-Id: <3@pe1kda.ampr.org>
  51. From: jelle@pe1kda.ampr.org (Jelle Aardema)
  52. Reply-To: pe1kda@pe1kda
  53. To: tcp-group@pa2aga
  54. Subject: swamik@ele.uri.edu
  55. X-Mailer: pc-mos/386 mailer testrel 1.75 (c) 1990 pe1jlj
  56. X-O/S: ms-dos
  57.  
  58.  
  59. To   : swamik@ele.uri.edu
  60. >From : jelle@pe1kda.ampr.org
  61.  
  62.  
  63. Shwamik,
  64.  
  65. Have a look at this TCP-Group Digest mail. I used this information myself
  66. to obtain the source files needed for putting the Sun IPX to AX25, by use of
  67. a KISS configured TNC on one of the serial ports.
  68.  
  69. Source code is available on UCSD.EDU by FTP, in compressed form: fully docu-
  70. mented and well described in 'where to modify what?'.
  71.  
  72. Please let me know if the software is unreachable: I still have it on floppy.
  73.  
  74. ----------------- 8<--- 8<---   cut here   8<--- 8<--- -----------------------
  75.  
  76.  
  77.     TCP-Group Digest            Wed, 22 Sep 93       Volume 93 : Issue  245
  78.  
  79.     Today's Topics:
  80.                         KA9Q base code and scrollback
  81.                          SunOS 4.X AX25 kernel driver
  82.  
  83.     Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  84.     Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  85.     Problems you can't solve otherwise to brian@ucsd.edu.
  86.  
  87.     Archives of past issues of the TCP-Group Digest are available
  88.     (by FTP only) from UCSD.Edu in directory "mailarchives".
  89.  
  90.     We trust that readers are intelligent enough to realize that all text
  91.     herein consists of personal comments and does not represent the official
  92.     policies or positions of any party.  Your mileage may vary.  So there.
  93.     ----------------------------------------------------------------------
  94.  
  95.     Date: Wed, 22 Sep 93 07:31:45 UTC
  96.     From: wj8q@wsu.n8fow.ampr.org
  97.     Subject: KA9Q base code and scrollback
  98.     To: tcp-group@ucsd.edu
  99.  
  100.     Hiya..
  101.     Just a note- I'm the one that had the problem. I have since figured out
  102.     what it was. I'm not sure if it was intended to work this way or not, but
  103.     what happens is that it won't open the TMP files into any TMP environment
  104.     setting set to a root directory of a drive. I had my TMP environment
  105.     set to a ramdrive, d:\, and it wouldn't do any temp file opening.
  106.     Same on testing using main drives, etc-But I kept setting to root and
  107.     it didn't help--
  108.     Once I made a directory in the ramdrive + set my TMP environment to that
  109.     drive+directory, no problem.
  110.  
  111.     Thought I'd let y'all know.
  112.     73's,
  113.     Wes
  114.     _______
  115.     SMTP/Internet: wj8q@hamgate.cc.wayne.edu
  116.               LAN: wj8q@wsu.n8fow.ampr.org
  117.                  : Wj8q@wj8q.ampr.org : 44.102.40.18
  118.  
  119.     ------------------------------
  120.  
  121.     Date: Wed, 22 Sep 1993 01:02:01 -0700 (PDT)
  122.     From: William.Dorsey@Corp.Sun.COM (Bill Dorsey)
  123.     Subject: SunOS 4.X AX25 kernel driver
  124.     To: tcp-group@ucsd.edu
  125.  
  126.     Hi,
  127.  
  128.     Earlier, I asked a question about setting netmasks and broadcast addresses,
  129.     and setting up routing on a Sparcstation running SunOS 4.X and the AX25
  130.     kernel driver in the /hamradio/packet/sun directory on ucsd.edu.  I was
  131.     able to establish outgoing connections from my machine to other hosts on
  132.     amprnet, but they were not able to establish connections with me.  I was
  133.     led to believe this was because I didn't have routing set up correctly,
  134.     or perhaps because I was using the wrong netmasks.
  135.  
  136.     After having spent many hours pulling my hair out trying to figure out
  137.     what was going on, I finally bit the bullet and began sprinkling some
  138.     printf's in the AX25 driver to see what was going on.  After a few more
  139.     hours of debugging, I realized that incoming ARP requests weren't being
  140.     answered.  As you can see below from the context diffs between the orig-
  141.     inal tty_ax.c and my tty_ax.c, this is because the network interface
  142.     ethernet address was being compared against the ax25 broadcast address
  143.     in code which determines whether or not a packet is destined for our
  144.     host.  This is incorrect, and should be a comparison between the incoming
  145.     ethernet address and the ethernet broadcast address.
  146.  
  147.     The original code would never pass ARP requests (which have their ethernet
  148.     destinations set to be the ethernet broadcast address) to our host to the
  149.     kernel, and thus the kernel would never generate an ARP reply.  This
  150.     prevents other stations from establishing a connection to the Sun, and
  151.     thus severely limits the utility of the driver.
  152.  
  153.     I hope this is useful to someone...  The full source code to the driver is
  154.     available for anonymous ftp from n3lmf.ampr.org.  The connection is very
  155.     slow and the w6yx gateway seems to be down a lot, so if there is much
  156.     demand, I can put it on ucsd.edu.
  157.  
  158.     *** tty_ax.c.old   Fri Sep  3 14:24:18 1993
  159.     --- tty_ax.c    Tue Sep 21 19:46:30 1993
  160.     ***************
  161.     *** 472,478 ****
  162.             ax_ax2ether(ax->ah_dst, &oureth);
  163.             if( bcmp((caddr_t)&oureth, (caddr_t)&axp->arpcom.ac_enaddr,
  164.                 sizeof oureth) &&
  165.     !           bcmp((caddr_t)ax25broadcastaddr, (caddr_t)&a->arpcom.ac_enaddr,
  166.                 sizeof oureth)) {
  167.                     *forusp = 0;
  168.             }
  169.     --- 472,478 ----
  170.             ax_ax2ether(ax->ah_dst, &oureth);
  171.             if( bcmp((caddr_t)&oureth, (caddr_t)&axp->arpcom.ac_enadd
  172.                 sizeof oureth) &&
  173.     !           bcmp((caddr_t)&oureth, (caddr_t)ðerbroadcastaddr,
  174.                 sizeof oureth)) {
  175.                     *forusp = 0;
  176.             }
  177.  
  178.     --
  179.     Bill Dorsey                     william.dorsey@corp.sun.com
  180.     PGP 2.X public key              n3lmf@n0ary.#norcal.ca.us.na
  181.     available on request            dorsey@n3lmf.ampr.org
  182.  
  183.     ------------------------------
  184.  
  185.     End of TCP-Group Digest V93 #245
  186.     ******************************
  187.  
  188.  
  189. ----------------- 8<--- 8<---   cut here   8<--- 8<--- -----------------------
  190.  
  191.    Jelle Aardema : PE1KDA @ PI8NVP.NH.NLD.EUR  : AX25 BBS
  192.                    pe1kda @ pe1kda.ampr.org    : ampr Internet [44.137.36.55}
  193.                    aardemaj @ ges.getronics.nl
  194.  
  195. ----------------- 8<--- 8<---   cut here   8<--- 8<--- -----------------------
  196.  
  197. ------------------------------
  198.  
  199. Date: Thu, 30 Dec 1993 18:37:26 -0800
  200. From: karn@qualcomm.com (Phil Karn)
  201. Subject: What does this mean?
  202. To: kf5mg@kf5mg.ampr.org
  203.  
  204. Assuming that the system returning you those source quenches is running
  205. something close to my original NOS code, the most likely reason you're
  206. getting them is because k5vr's system is not on the air.
  207.  
  208. NOS can return source quenches for several different reasons, but the
  209. most common in AX.25 operation is an unresolved ARP. When a NOS system
  210. with an AX.25 interface tries to send or forward a packet to an IP
  211. address that's not in the ARP cache, ARP saves the packet and
  212. broadcasts an ARP request instead. It holds onto the original packet
  213. for something like 15 seconds, pending a response. If the ARP response
  214. comes back in that time, the original packet is then forwarded
  215. normally. If the ARP doesn't come back in 15 seconds, the original
  216. packet is silently discarded (a purist would argue that it should be
  217. bounced with a destination unreachable, but this still breaks too many
  218. TCPs).
  219.  
  220. Now if additional packets arrive for a target that's still pending ARP
  221. resolution, they are immediately returned with a source quench; you
  222. can only have one outstanding packet on the queue at a time. And if
  223. the target station isn't on the air, the ARP will never be resolved.
  224. And if you try to send more than one packet to such a station every
  225. 15 seconds, you'll see the source quenches.
  226.  
  227.  
  228. So the bottom line is this: repeated source quenches from a gateway
  229. transmitting on an AX.25 channel are a very good indication that the
  230. next station on the path is down or unreachable and has been so for
  231. more than 15 minutes (the ARP cache timeout).
  232.  
  233. Phil
  234.  
  235. ------------------------------
  236.  
  237. End of TCP-Group Digest V93 #339
  238. ******************************
  239. ******************************
  240.